Cross-platform event engine

ABSTRACT

A system for handling event input between disparate platforms includes a memory containing instructions executable by the processor whereby the system is operable to recognize an event associated with a first platform, the event having semantic content, translate the event into a form recognizable by a second platform, and communicate the event in the translated form to the second platform. The second platform is configured for effectuating the semantic content of the event

CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims priority to U.S. patent application Ser. No.14/583,655 entitled “Intelligent Rendering of Information in a LimitedDisplay Environment”, which claims priority to U.S. patent applicationSer. No. 12/970,452 filed on Dec. 16, 2010 entitled “Intelligent Renderof Information in a Limited Display Environment”, which claims priorityto U.S. patent application Ser. No. 11/227,013 filed on Sep. 14, 2005entitled “Intelligent Render of Information in a Limited DisplayEnvironment”, now U.S. Pat. No. 7,877,703, which claims priority to U.S.Provisional Patent Application No. 60/661,757 filed on Mar. 14, 2005entitled “Agnostic User Interface for Use in Mobile Devices.” The entiredisclosure of all of these applications is incorporated by referenceherein.

The application is related to U.S. patent application Ser. No.11/123,540 filed on May 5, 2005 entitled “Universal Text-Entry.” Thisapplication is related to U.S. patent application Ser. No. 11/227,323filed on Sep. 14, 2005 entitled “Cross Platform Event Engine.” Theapplication is further related to U.S. patent application Ser. No.11/227,272 filed on Sep. 14, 2005 entitled “Platform Neutral UserInterface for Mobile Devices.” The entire disclosure of each of theseapplications is incorporated by reference herein.

FIELD OF THE INVENTION

The present invention generally relates to the field of user interfaces.More specifically, the present invention relates to the use of userinterfaces across various operating platforms in various mobile devices.

DESCRIPTION OF THE RELATED ART

Mobile data access devices make it simple and affordable to accesscorporate and personal data while out of the office. Software allowingfor such access is becoming a standard feature on a variety of mobiledevices and platforms: BREW, Pocket PCs, Smartphones, Symbian-basedphones, PDAs and Internet browsers.

There are approximately 35 million workers that make up the ‘mobileworkforce,’ that is, individuals who carry out all or substantialportions of their job away from a physical office setting. Despite theincreasing number of on-the-go workers, electronic mail remains,arguably, the most important business application. As a result, thisworkforce and the casual individual user have an inherent need forwireless access to their electronic mail and other data.

Despite the pervasiveness of electronic mail and an ever-increasing needfor access to electronic mail and data, costs of ownership for mobiledata access remains a barrier. The issue is no longer whether mobiledata access is a necessity but whether it can be deployed and managed inan effective manner.

While cost is an obvious concern in equipping the workforce with themeans for accessing data on-the-go, the implementation, development,integration and management of mobile data access solutions are also akey concern. And while mobile devices are becoming a staple in personaland commercial enterprise, other rapidly evolving changes such as numberportability, mergers in the telecom industry and the lack of any oneparticular technical standard in the mobile device technological space,make providing support for a wide-array of devices as important an issueas any with regard to accessing data from a mobile device. The lack ofinternal expertise, the immaturity of standards, complexity ofintegration, device limitations, and application development have allbeen explicitly recognized as barriers to adopting mobile devices forproviding access to data while, for example, out of the office or awayfrom a personal desktop computer.

Increased device flexibility as may be provided by device agnosticsoftware allows for consolidation of multiple application utilities andalso reduces overall outlays on hardware (e.g., a single application canbe run on various mobile devices and as could a piece of hardware, suchas a synchronization cable). This flexibility also improvesIT-familiarity and expertise and, likewise, with end users, which betterensures adoption of mobile device technologies in their fullest sensethereby better ensuring a return on investment.

As adoption and pervasiveness of mobile devices and operating platformsincrease, developing agnostic applications for mobile devices makesapplication development and testing less of a colossal task for softwareengineers, quality assurance professional and human factor engineers.The result is better design and quality assurance.

User interfaces play a critical role in mobile device development inthat they must not only provide users with access to mission criticaldata but deal with the realities of variations in screen size, pixeldensity, aspect ratio and screen use availability; limited memory on amobile devices client; limited processing power; general quirkinessbetween platforms; and, perhaps most noticeable to the end-user, thelimited physical space for interface with the mobile device. A keyboard,mouse or even a stylus are normally not available in a traditionalwireless or mobile device. Not only is input difficult, so is viewing adisplay rendering information. This is especially true when the mobiledevice happens to also be a cellular telephone.

One solution has been to utilize XML instead of HTML for pushingcontent. Using Extensible Stylesheet Language (XSL) allows forXML-formatter content to be transformed into HTML or other formats as aparticular mobile device might require.

Nevertheless, engineers must still deal with the fact that one interfacewill, often, not be suitable for more than one primary set of devices.For example, PDAs utilize a stylus and touch-screen while WAP-compliantmechanisms support telephony through, for example, WTA.

Even if a designer is satisfied with limiting an interface to aparticular device, the engineer must still deal with the nuances ofparticular device manufacturers (e.g., a Palm PDA versus a Nokia cellphone) and, in some instances, particular device models (e.g., PALM VIIxversus Nokia 7110).

An engineer is still, in many instances, limited by the fact that theymust pre-generate static content and generalize possible permutations ofthe interface as they pertain to a particular device family. Thisresults in delays for delivery of applications, increased costs inresearch and development, which inevitably result in increased costs forthe end user.

There is, therefore, a need in the art for a user interface that isagnostic with regard to operating platform and device wherein one clientwill work on multiple platforms and devices.

It should be noted, in the course of this disclosure, that while adevice and platform are recognized as distinct—albeit related—entities,any reference to a device or a platform should be considered inclusiveof both. Similarly, any reference to the agnosticism of an interfaceshould also be interpreted as agnosticism for both a device and aplatform.

Further, it should be noted that the disclosed agnostic user interfaceis not dependent on the presentation or transmission of communicationsdata (e.g., electronic mail, calendar, SMS) or utilization of user data(e.g., data stored on a desktop).

SUMMARY OF THE INVENTION

The present invention advantageously provides an advantageous virtualplatform agnostic to physical device or operating platform and comprisedof an abstraction layer that allows for portability across any varietyof mobile devices or operating platforms, especially with regard to userinterfaces. The virtual platform and its abstraction layer allow for auser interface on a first device to appear identical on a second deviceregardless of differences or limitations that may exist betweenoperating system platforms or devices. By providing an agnostic userinterface application, a user can move effortlessly between devicesshould, for example, the need for replacement or repair of a particulardevice arise.

Additionally, the agnosticism of the interface application makes itpossible for software developers and engineers to utilize one test suitefor a variety of devices or platforms when introducing new featuresthereby reducing lag-time in getting application to market as well asR&D costs, which inevitably translates into savings for the end-userand/or profit increases for the application and/or devicedeveloper/manufacturer.

The present invention also provides an advantageous means ofhighlighting or focusing information on a device to minimize the displayof unnecessary or interfering information relative to presentlyimportant or critical data to be observed by a user.

The present invention also provides advantageous intelligence withregard to the display of information on an as-possible, as-needed and/oras-preferred basis.

The present invention also provides an advantageous layout enginewherein non-compatible graphics and/or text to be displayed on aparticular device can be dynamically altered prior to rendering so thatthey are rendered without significant layout errors or disruptions inthe user's viewing of the information. Methods for configuring thelayout of information are also provided.

The present invention also provides advantageous means of arranginginformation on a mobile device in conjunction with a layout enginethrough the use of coordinate positioning of information and/or vectordrawing.

The present invention also provides an advantageous cross-platformevents engine for synthesis of a variety of events and uniformly actingon disparate event sets wherein an event request as might be recognizedon one device is translated into a native request recognized on a seconddevice through abstraction and code sharing. Methods for determining theportability of an event from a first device to a second device are alsoprovided.

The present invention also provides an advantageous means of drivingtext-entry mechanisms whereby difficulties with adjusting to devicespecific constraints such as timeout periods associated triple-tap textentry or pictographic language are overcome through the use of anoff-screen text buffer. Methods for the entry and display of text arealso provided.

The present invention also provides an advantageous means of managinginformation on a mobile device utilizing five-way navigation.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1A illustrates an exemplary embodiment of a device platformincluding various operational layers for interaction with a particulardevice client.

FIG. 1B illustrates a device platform including various operationallayers for interaction with a particular device client as is generallyfound in the prior art.

FIG. 2A illustrates a balance of platform specific code and platforminterchangeable code as may generally be found in the prior art.

FIG. 2B illustrates an exemplary embodiment of an abstraction layer anda balance of platform specific code and platform agnostic code as may befound in an agnostic interface.

FIG. 3 illustrates an exemplary embodiment of an abstract layercomprised of various informational modules.

FIG. 4 illustrates an exemplary embodiment of a virtual platformcomprised of a shell program and an abstract layer.

FIG. 5A illustrates the differences in screen display ratio for twodifferent client devices as found in the prior art.

FIG. 5B illustrates the problems often associated with a single graphicelement rendered on different client devices with different displayratios as found in the prior art.

FIG. 6A illustrates exemplary relative adjustments in an agnostic userinterface.

FIG. 6B illustrates exemplary dynamic adjustments in an agnostic userinterface as they pertain to a global scaling feature.

FIG. 6C illustrates exemplary dynamic adjustments in an agnostic userinterface as they pertain to a zooming feature.

FIG. 6D illustrates exemplary dynamic adjustments as they pertain to a‘quick-look’ or ‘short attention span’ feature in an agnostic userinterface.

FIG. 7A illustrates a layout engine for controlling an agnostic userinterface.

FIG. 7B illustrates an exemplary relationship between an abstractionlayer and a rules engine as might be present in a layout engine in oneembodiment of the present invention.

FIG. 8 illustrates the exemplary rendering of a graphic image throughthe use of a coordinate layout system.

FIG. 9 illustrates the exemplary rendering of graphic informationaccording to hierarchical limitations and requirements.

FIG. 10A illustrates a menu with available and not-available options asin known in the prior art.

FIG. 10B illustrates a menu exhibiting intelligent prioritization ofmenu commands as governed by their present availability according to anexemplary embodiment of the present invention.

FIG. 10C illustrates a menu exhibiting intelligent prioritization ofmenu commands as governed by presently available and user preferredcommands according to an exemplary embodiment of the present invention.

FIG. 11A illustrates icons on a display with no particular limitationsas to their rendering.

FIG. 11B illustrates icons on a display with display limitations whereinthe icons are intelligently selected in an exemplary embodiment of thepresent invention.

FIG. 12 illustrates a cross-platform event engine as may be utilized inan exemplary embodiment of the present invention.

FIG. 13A illustrates a portion of a keypad as might be utilized intriple-tap or triple-press text entry on a mobile device as is known inthe prior art.

FIG. 13B illustrates a mobile device utilizing the T9 text-entrymethodology as is known in the prior art.

FIG. 14A illustrates an exemplary embodiment of the present inventionwherein an on-screen text box is synchronized with an off-screen textbuffer.

FIG. 14B illustrates a string of text as may be found in an off-screentext buffer in an exemplary embodiment of the present invention.

FIG. 15 illustrates an exemplary method for utilizing an off-screen textbuffer in an embodiment of the present invention.

FIG. 16 illustrates an exemplary method for utilizing a layout engine todisplay graphics and/or text in an embodiment of the present invention.

FIG. 17 illustrates an exemplary method for utilizing a cross-platformevents engine to execute cross-platform events in a native environmentin an exemplary embodiment of the present invention.

FIG. 18A illustrates the display of information on a mobile device asmay be found in the prior art.

FIG. 18B illustrates the exemplary management of information displayedin FIG. 18A using five-way navigation in an embodiment of the presentinvention.

DETAILED DESCRIPTION OF AN EXEMPLARY EMBODIMENT

FIG. 1A illustrates an exemplary embodiment of a device platformincluding various operational layers for interaction with a particularclient device. The present embodiment comprises a platform 110,abstraction layers 120, synchronization module 130, user interfaceframework 140, and client device 150.

Some embodiments of the present invention may comprise additionaloperational layers such as open or proprietary application programinterfaces (APIs) that allow software engineers, programmers, and otherusers to author or install applications that are consistent with theparticular platform's operating environment. Some embodiments of thepresent invention may also lack certain operational layers, such as thesynchronization layer, should a particular device or platform notprovide for synchronization operations.

The platform 110 is the underlying hardware or software for a particularoperating environment. Platform 110 also defines a standard around whichthe particular operating environment is developed, that is, around whichsoftware, hardware and other applications can be developed. An exampleof the platform 110 is the Nokia Series 40 Developer Platform, which canutilize platform technologies such as Java™ J2ME or the Nokia Series 60and Series 80 Developer Platforms, which can utilize C++ in addition toJava™ J2ME platform technologies. Similarly, the Palm OS® Platformsupports native programming in C and C++ languages as well as supportingJava programming via third-party Java Virtual Machines.

Abstraction layers 120 are composed of basic functionalities that allowfor, in part, the integration of platform 110 with client device 150 aswell as other operational layers such as synchronization module 130 anduser interface framework 140. The abstraction layers 120 also declareclasses, interfaces, and abstract methods intended to support variousfunctions and system operations in any particular platform 110.Abstraction layers 120 may be open or proprietary and are often composedof various modules (e.g., FIG. 3).

Optional synchronization module 130 comprises the various operationalinstructions, functionalities, and code necessary to allow a particularclient device 150 to synchronize with an external device, such as adesktop personal computer or enterprise server. Synchronization can beachieved in a variety of ways including a cable-to-handsetsynchronization mechanism whereby the client device 150 is physicallycoupled to a desktop personal computer to allow for the exchange andsynchronization of data (e.g., electronic mail). Synchronization andoptional synchronization module 130 are not to be construed as necessaryfor the operation of an agnostic user interface.

Synchronization can also be achieved wirelessly whereby an enterpriseserver (e.g., a Microsoft Exchange Server) configured with appropriatesoftware (e.g., SEVEN Server Edition from SEVEN Networks, Inc.) and withaccess to a wireless gateway allows for real-time access to electronicmail and other data by the client device 150 without any physicalconnection to the enterprise server. While the synchronization module130 may be necessary for synchronizing the client device 150 and otherexternal device (e.g., a server), the presence of such a module is notmeant to be interpreted as a prerequisite for the operation of anagnostic user interface.

User interface framework 140 comprises various libraries and source codeto allow for the rendering of a user interface on a particular clientdevice 150. User interface framework 140 libraries include elements suchas icons, cursors, scroll bars, sounds, animations, etc.

Client device 150 is any device coupled to a network (e.g., wirelessly)that allows for access to a server device or other computing entity,such as a second client device. Through the coupling of the clientdevice 150 to the server, the user of the client device 150 cansynchronize data such as electronic mail or access data. Examples ofclient device 150 include Pocket PCs, Smartphones, and PDAs. Clientdevices 150 are increasingly mobile. This mobility is often a directresult of integrating the client device 150 with, for example, acellular telephone although it is not necessary for the client device150 to be integrated with a mobile phone or any other device. Clientdevices 150 are often associated with a particular platform 110.

For example, the aforementioned Nokia Series 40 Developer Platform isassociated with the Nokia 6101 and 6102 model client devices as well asthe Nokia 6020, 6235, 6235i and 6822 model client devices. The NokiaSeries 60 Developer Platform, on the other hand, is associated withclient devices such as the Nokia 6680, 6681, and 6682 model devices.Similarly, the Palm OS® Platform is associated with client devices suchas Xplore™ G18, Kyocera 7135, and the Treo™ 650.

FIG. 1B illustrates a device platform including various operationallayers for interaction with a particular device client as is generallyfound in the prior art.

A device platform found in the prior art shares limited similaritieswith a device platform as might be found in an embodiment of the presentinvention in that a prior art device platform comprises the actualplatform and various operational layers such as synchronization modules,APIs, and so forth. Prior art device platforms differ from a platform asmight be found in an embodiment of the present invention in that theclient, user interface framework and abstraction layer are moreintegrated and operationally incorporated (160) as compared to thepresent invention (170). The ‘tightly wound’ nature of prior art devicesis often the result of a general lack of portability of a user interfaceor any other aspect of the particular platform between various clientdevices. That is, a particular user interface and accompanyingabstraction layer are written exclusively for a particular platform andexclusively for a particular device solely in conjunction with thatplatform.

The exemplary device platform illustrated in FIGURE lA evidences theability to transport various aspects of a particular platform (e.g., auser interface) from one client device 150 to the next, especially withregard to the design of the abstraction layer 120 as is furtherdiscussed in the context of FIGS. 2A and 2B, below.

It should be noted that while FIGURE lA illustrates various operationallayers as separate elements, this is not to suggest a necessary physicaldifferentiation or a general lack of integration in an embodiment.Similarly, the integration of the client, user interface framework andabstraction layer (160) in FIG. 1B is not meant to suggest a literal,physical integration. These illustrations are provided merely to aid inthe perception of the ‘tightly wound’ and vertically integrated aspectsof a prior art device platform versus a device platform, as in anembodiment of the present invention, allowing for portability of, forexample, a user interface from one device to another.

FIG. 2A illustrates a balance of platform specific code 210 and platformagnostic code 220 as may generally be found in the prior art.

For example, and as described in the context of FIG. 1B, prior artplatform devices are unitary in nature and not meant to allow forportability of features, such as a user interface. As such, a prior artabstraction layer 200 is comprised predominantly of platform-specificand device-specific code 210. This particularized code, while allowingfor the integration and operation of a particular device on a particularplatform, inhibits the portability of any particular features from onedevice to another (e.g., a user interface) as might otherwise beprovided for with more general or agnostic code 220. Agnostic code 220might comprise code written in accordance with particular industrystandards or specifications but that allows for the portability orinteroperability of a specific and particular feature amongst devices.

FIG. 2B illustrates an exemplary embodiment of an abstraction layer 250and a blend of platform specific code 260 and agnostic code 270 as mightbe found in an agnostic user interface.

An abstraction layer 250, as may be found in an embodiment of thepresent invention and as illustrated in FIG. 2B, exhibits a much‘thinner’ layer of platform- or device-specific code 260. Abstractionlayer 250 with its thin layer of platform- or device-specific code maybe, generally, the type of abstraction layer 120 as described in FIG.1A. As the abstraction layer 250 is comprised more of standardized oragnostic code 270, the portability or interoperability of particularfeatures is increased in that a feature will operate on variousplatforms or devices due to its coding being dependent more on thegeneralized code 270 than with platform- or device-specific code 260that limits or inhibits portability or interoperability.

FIG. 3 illustrates an exemplary embodiment of an abstract layer 310comprised of various informational modules 310-350.

Informational module 310-350 are routines and instructions as theypertain to various operational features of a particular platform 110and/or client device 150 linked in the abstraction layer 310. Forexample, resource module 320 may comprise specific data or routinesutilized in the operation of platform 110 and/or device 150 (e.g., sleepmode, power on and off). Graphics module 330 may comprise specific filessuch JPEGs, bitmaps or other graphic data that could be utilized by userinterface framework 140 in its rendering of a user interface on clientdevice 150. Event module 340 may comprise a library of actions oroccurrences as might be detected by a particular program such as useractions (e.g., pressing a key) in addition to system occurrences (e.g.,an internal calendar alarm). Sound module 350 may comprise varioussounds (e.g., WAV files) to be generated in response to, for example,the occurrence of certain system events (e.g., system warningsconcerning low battery power).

Abstract layer 310, as it corresponds to abstract layer 120 (FIG. 1) andabstract layer 250 (FIG. 2) may comprise additional or less modules asis required by the particular platform 110 and/or client device 150. Itshould also be noted that while FIG. 3 illustrates various modules asseparate elements, this is not to suggest the requirement of a physicaldifferentiation or a general lack of integration in an embodiment of thepresent invention.

FIG. 4 illustrates an exemplary embodiment of a virtual platform 400comprised of a shell program 410 and an abstract layer 420.

Abstract layer 420 is a layer similar to that described in FIG. 3.Abstract later 420 interacts with a shell program 410 to effectivelytranslate or otherwise offer portability of commands or instructionsfrom one platform or device to a second platform or device. For example,if an event 430 (e.g., an extended button press) occurs on a particularplatform (e.g., the Nokia Series 40 Developer Platform) that event 340may not be immediately recognized on a Palm OS® platform; the virtualplatform 400 provides the necessary translation between the two.

The event 430 or certain information generated by the event 430 isintercepted by the shell program 410. The shell program 410 prevents theevent 430 or the information generated by the event 430 from beingimmediately processed by any relevant logic on the device or platform.The abstract layer 420 then processes the event 430 intercepted by theintermediary shell program 410 and determines the proper response 440 tothe event 430 for the particular platform hosting the virtual platform400.

For example, the extended button press on the Nokia Series 40 DeveloperPlatform, in that particular operating environment, might be equated toactivating a backlight for a display screen. In another operatingenvironment, however, an extended button press might be associated withsending a device into a ‘sleep’ state or may lack an associated functionaltogether. In this instance, and absent the virtual platform 400, if aNokia platform were operating on a Treo™ 650 device, an extended buttonpress by the user that was meant to activate the backlight could resultin sending the device into hibernation or even a system crash for lackof an associated command string.

Utilizing the virtual platform 400, however, the shell program 410 wouldintercept and recognize the Nokia platform button press event 430 andcommunicate with the abstract layer 420 in order to translate the event430 into the proper related response 440 for the Treo™ device, whichmight normally be a double press of a particular button.

FIG. 5A illustrates the differences in screen display ratio for twoprior art client devices, specifically a TREO™ 650 510 and a Nokia 6680520. In the case of the TREO™ 650 client device, the screen displayoffers 320×320 pixel-width with 16-bit color; the display offersapproximately 65,000 colors. In the case of the Nokia 6680 clientdevice, the screen display offers 176×208 pixel-width with activematrix; the display offers approximately 262,144 colors.

FIG. 5B illustrates the problems often associated with a single graphicelement rendered on different client devices with different displayratios as found in the prior art. For example, a graphic 530 might beapproximately 300 pixels in width and renders without issue on device510 with a 320 pixel-width. That same graphic, in the context of device520 with a 176 pixel-width, however, might be distorted 540 in that itis ‘cut off’ due to the limited screen width. This distortion is oftenthe result of different devices and/or platform rendering the samegraphic. This distortion can be especially problematic in the context ofuser interfaces offered by third-party software service providers eitherfor functionality and/or branding purposes.

The agnostic user interface as described herein aids in preventing,inter alia, inevitable pixel variances and other differences betweendevices and/or platforms from resulting in the distorted 540 image asshown in device 520 in FIG. 5B. The agnostic user interface will specifya particular layout but also provide for adjustment of the interfacedepending on the particular nuances of any particular platform ordevice, for example, screen width as evidenced in FIGS. 5A and 5B. Theseadjustments can be relative (e.g., as a result of screen width) or ‘asneeded’ or ‘dynamic’ per the particular demands of a user of anyparticular device.

An example of relative adjustments in a client device is illustrated inFIG. 6A. Client device 605 is similar in size to client device 510 inFIGS. 5B and 5A (320×320). Graphic 610 is rendered on client device 605in a size that is relative to the pixel limitations of the screen.Graphic 620 is similarly rendered on client device 615, which is similarin size to client device 520 in FIGS. 5B and 5A (208×176). Instead ofgraphic 620 appearing distorted as it did in FIG. 5B (540), the platformagnostic interface has provided a generally identical screen layout butmade automatic adjustments for the graphic 620 to appear relative to theconstraints of the client device 615.

FIG. 6B illustrates dynamic adjustments in a user interface as theypertain to a global scaling feature. In some instances, a particulardevice will be unable to allow for relative adjustment of a userinterface. This might be a result of screen size limitations or theinability to render certain graphics. In these instances the agnosticuser interface can make intelligent decisions with regard to whatinformation should be relatively adjusted, which information cannot berelatively adjusted (for varying reasons, for example, the criticalimportance of certain information), and certain information which shouldbe dropped from the display altogether.

As shown in device 625, a display screen is shown with certain userinterface information 635 such as a tool bar and various short-cut keyssuch as phone, home, contacts, trash, notes, and electronic mail. In adevice 630 with limited screen size, relative adjustments to all thisinformation might make the short-cut key and tool bar entirely illegibledue to excessive decreases in size and/or overcrowding on the display.In these instances, the agnostic user interface will make intelligentdecisions with regard to what information must remain present and thelimits on certain relative adjustments of information.

For example, in device 630 with a platform agnostic user interface, userinterface information 640 has been adjusted to address the limitationsof the screen size. Specifically, certain short-cut keys (electronicmail, home, contacts, and phone) have been entirety removed from thedisplay. While these functionalities remain present in the device, theirshort-cut key has merely been removed from the screen and now requires abutton-press or access through a tree-menu or some other means of accessas might be dependent on the exact structure of the user interface.Additionally, while other short-cut keys have been reduced in size,other keys remain more prominent. This can be a result of defaultsettings that identify certain features as being more mission criticalthan others or as a result of specific user settings.

An example of dynamic adjustment in a user interface as it pertains to azooming feature is illustrated in FIG. 6C. For example, a user device645 is shown listing several electronic mails of the user. In an effortto provide the user with as much information as possible, electronicmail information is presented in a small font size making it difficultfor a user to sometimes comprehend the information presented on thedevice 645. Utilizing a dynamic adjustment zooming feature, as a userscrolls up and down the list of electronic mails, a highlighted orselected electronic mail 650 is magnified or ‘zoomed’ whereby the fontsize is increased and all other electronic mails present on the device645 are either further reduced in size whereby all information remainson the screen but in varying sizes or certain electronic mail listingare ‘dropped’ from the screen (e.g., instead of ten commonly sizedelectronic mail listings, zooming-in on any particular electronic mailmessage will result in one magnified message and seven messages at theoriginal size with the other two messages ‘dropped’ from the screen).

FIG. 6D illustrates dynamic adjustments in a user interface as thoseadjustments might pertain to a ‘quick-look’ or ‘short attention span’feature. For example, providing the user with all possible availableinformation and in a minute font size may be appropriate when a user ofdevice is able to provide their undivided attention to the device andfocus attentively on that information as is shown in device 655. Indevice 655, the user is presented with time and date information 660,various feature or short-cut keys 665 (e.g., phone, Internet, electronicmail, calendar, contacts, notepad) and a tool bar 670.

In some instances, however, a user may be unable to direct theirundivided attention to their device as they might be walking whilereviewing their device or driving a vehicle. In these instances, theuser is forced to divide their attention; for example, ensuring the userdoes not accidentally walk into another person or veer off the road. Theuser, to the extent it is necessary for them to access their device withdivided attention, often only need to take a ‘quick-look’ atinformation. Device 675 illustrates a user interface whereby a ‘quicklook feature’ is enabled whereby only essential information isdisplayed. For example, in device 675 with a quick-look interfaceenabled, the user is still presented with time and date information 680but that information is enlarged in size and takes up twice as muchspace as the time and date information 660 in non-quick-look enableddevice 655. Additionally, the short cut keys 685 have been reduced innumber to only those of utmost importance. In this case, those keys arephone, calendar, and contacts and they are displayed at nearlythree-times their normal size. Further, the tool bar 690 has beentotally dropped from the screen as it is unlikely a user will beperforming maintenance or adjusting settings on their device 675 whileonly able to offer a short amount of attention.

In a short-attention span or quick-look mode, the adjustment andselection of features to be displayed and, likewise, those featuresremoved from the display can be set by default (e.g., factory settings)or they can be modified by the user as they reflect the user's needs.Furthermore, using an agnostic user interface, the displayed informationwill adjust in size as is set forth by the default settings or the userin conjunction with certain limitation posed by the actual device (e.g.,screen size).

FIG. 7A illustrates an embodiment of a layout engine 700 that may befound in particular embodiments of the presently described agnostic userinterface. Layout engine 700 comprises a rules engine 720 and a logicengine 730. An embodiment of the layout engine 700 provides intelligentflexibility for adjusting interface layout (e.g., spatialinterrelationships between elements and/or information and/or structuralaspects therein) to fit multiple screen sizes, densities and aspectratios.

Rules engine 720 comprises a variety of defined constraints with regardto the display of user information on the display of a device. Forexample, rules engine 720 may be programmed to understand that theparticular device on which the rules engine 720 resides has a limitedscreen size in terms of pixels or limitations with regard to the numberof colors the display can render. Other rules might include this displayof certain language or file formats (e.g., HTML, *.pdf, or *.ppt).Additional rules may be related to limitations on dedicated processingpower for the rendering of any particular graphic as it pertains to thegeneral operation of the device or during a particular operation (e.g.,while downloading content from a website).

The constraints delineated in the rules engine 720 can be installed byan original equipment manufacturer or may be subject to user adjustment(e.g., deactivating default settings). Constraints in the rules engine720 may also be updated automatically during the operation of the deviceor configured as the result of intelligent determinations by the device.

For example, if a rules engine 720 determines that it is resident on adevice for which it does not know the pixel limitations of the display,it can make certain assumptions as to the display size. The rules engine720 might recognize that the layout engine 700 is resident on a Nokia6600 Series phone but not that it is on a Nokia 6680 phone, inparticular. From the rules engine's 720 knowledge of the Nokia 6600Series, it can make an assumption that the pixel limitations are ‘atleast’ or ‘at most’ certain numbers. As a result, the layout engine 700may not produce an optimized graphic image on the device but at leastone sufficient to operate and not cause a degraded viewing experiencelike that shown in FIG. 5B (520).

The rules engine 720 can also receive new updates with regard to deviceinformation during a synchronization operation with a desktop PC orserver that hosts other programs related to the device (e.g., a mailforwarding program that forwards mail from the desktop to the mobiledevice). These updates might be downloaded at the desktop PC or serverautomatically or as a result of the user affirmatively downloading anupgrade or patch from the appropriate provider of that information(e.g., the device manufacturer or the agnostic interface designer).

The rules engine 720 can also request the user manually provide thisinformation if an assumption or synchronization operation fails toprovide the necessary information.

An input request 710 from the user of the device or a program running onthe device comprises a request to display certain information on thedevice; for example, a text box of x*y pixel size or a particular color.As noted, this request might be generated by the user during the courseof using a drawing application. Similarly, this request might begenerated by a particular program as a result of the occurrence of aparticular event, for example, an alarm indication that generates a textbox indicating a certain event is about to begin. The input request 710need not be of any particular format or language so long as it may beprocessed by the layout engine 700 with regard to determining whetherthe particular text and/or graphic event may be displayed on the devicein accordance with requested size, color, configuration, etc.

The layout engine 700 also comprises the aforementioned logic engine730. The logic engine 730, based on an input request 710, will query therules engine 720 to determine if the particular input request 710 may beprocessed as requested on the particular device or if some adjustmentswill be required with regard to the limitations of the device as setforth in the rules engine 720. For example, an input request 710 mightrequest the display of a text box of x*y size and of a particular shadeof aqua. The layout engine 700's logic engine 730 will identify therequested parameters (e.g., size and color) and make a query of therules engine 720 to determine if the particular device hosting thelayout engine 700 can accommodate the request 710. If the rules engine720 reflects that the request 710 can be processed and subsequentlyrendered without violating a particular rule, the logic engine 730 willapprove the request 710 thereby resulting in an output instruction 740.

Output instruction 740, like the input request 710, is not of anyparticular format or language so long as it may be generated by thelayout engine 700 with regard to indicating that a particular textand/or graphic event may be displayed on the device in accordance withrequested size, color, configuration, etc. Instruction 740 need only becapable of subsequently being processed by the appropriate component ofthe device providing for the display of the text and/or graphic event(e.g., a graphics or rendering engine (not shown)).

Should the logic engine's 730 query of the rules engine 720 determinethat the requested text and/or graphic event cannot be displayed on theparticular device, the logic engine 730 may further query the rulesengine 720 to determine what the particular constraints of the deviceare with regard to the rejected event (e.g., the device cannot displayaqua but can display light blue). This information might also residedirectly in the logic engine 730 or at a locale on the device accessibleby the engine 730. For example, information pertaining to commonlyrequested display events might be cached in the logic engine 730 or inmemory (not shown) accessible by the logic engine 730.

Similarly, the logic engine 730, in certain embodiments, may be trainedwhereby the logic engine 730 begins to recognize a repeated displayevent and without query to the rules engine 720, understands that such adisplay event is impossible or otherwise violates the rules of thedevice as set forth in the rules engine 720. Through the training of thelogic engine 730 and the now absent need for continued queries to therules engine 720, the processing speed of a display event may beincreased.

The logic engine 730, in some embodiments, may also be expresslyinstructed by the user (e.g., through pre-programming or a query duringprocessing) to respond to a particular violation of a constraint setforth in the rules engine 720 in a particular manner. For example, ifthe request 710 pertains to the display of aqua but the device can onlydisplay light blue, the user might pre-program the logic engine 730 todisplay sea-foam green instead of resorting to light blue.

Once the logic engine 730 determines the constraints of the particulardevice in conjunction with the requested event as reflected by the inputrequest 710, the layout engine will generate the output instruction 740that best reflects the scope of the initial request 710 but whileremaining within the particular constraints as set forth by the rulesengine 720 or, in some embodiments, as directly instructed by the user.For example, the logic engine 730 may resort to the aforementionedexample of light blue versus aqua.

By further example, if a request 710 pertains to the display of agraphic or text information that exceeds the size of the actual device(for example, as illustrated in FIG. 5B (540)), the logic engine maydetermine what information is necessary to be displayed to carry out thescope of the initial request 710.

For example, request 710 might pertain to displaying a user's contactsdirectory. On one device, the display of the directory might normallyresult in the concurrent display of the date and time as well as atelephone icon whereby a user can highlight a particular name in thecontact directory and then ‘tap’ the telephone icon resulting in thephone dialing the number of the person in the contact directory (i.e., aspeed-dial feature).

If the physical limitations of a particular device are such that thetime and date, directory and speed-dial icon cannot all be displayed,the logic engine 730 will determine what information is critical to thescope of the request 710 and, operating within the confines of the rulesengine 720, generate an output instruction 740 that will result in, forexample, the relocation of the speed-dial icon on the display to a moreefficient space, the reduction in size of the contacts directory (or thedisplay of only a limited number of names in the directory) and thetotal removal of the date and time from the display during thisparticular operation.

An embodiment of the layout engine 700 may also provide forcross-representation of resources such as bitmaps, templates or screenlayouts, animations and sounds.

As illustrated in FIG. 7B, the rules engine 720 of the layout engine 700may be integrated with the abstraction layer 420 of the virtual platform400 that allows for the interoperability of a particular user interfaceon any variety of devices and/or platforms. While the layout engine 700and virtual platform 400 need not necessarily be physically integrated,the agnostic user interface of the present invention requires that thetwo components at least be capable of communicating with one another asto allow for the translation of what might be a foreign instruction bythe virtual platform 400 into an instruction otherwise comprehensible bythe layout engine 700.

In some embodiments, the layout engine 700 may be further integratedwith a cross-platform events engine as is described in FIG. 12.

In some embodiments of the present invention, the rendering of anagnostic user interface will be effectuated utilizing vector graphicsalthough the rendering of agnostic user interface information may alsooccur through the use of other graphic rendering techniques. Vectorgraphics represent those graphic images generated from mathematicaldescriptions that determine the position, length, and direction in whichmathematically-describable objects—such as lines, ellipses, rectangles,rounded rectangles, abstract polygons, filled and non-filled regions,gradients, fountain fills, Bezier curves and so forth—are drawn. Unlikeraster graphics, objects are not created as patterns of individual dotsor pixels. Through utilizing vector graphics, the ‘look and feel’ of aparticular interface is maintained across platforms and devices therebyresulting in increased scalability as each element is stored as anindependent object.

Vector graphics also aid with regard to ‘skinning’ whereby the look of aparticular platform or software program is changes but its underlyingfunctionality remains unaltered. Through the use of skinning,opportunities for branding, advertising, and user customization are alsoincreased. Skinning also allows for platform independence whereby onecustomized user interface can be ported to various devices or operatingplatforms and because of the utilization of vector graphics versusrasterization or bitmapping, that one interface can be scaled andadjusted as necessary by, for example, a layout engine 700 and/orvirtual platform 400. The end result of using vector graphics is that‘real space’ remains consistent and relative.

Graphic renderings may also be expressed as a relationship between aparticular point and its location on a Cartesian grid (e.g., a gridsystem). For example, FIG. 8 illustrates such a Cartesian grid 800. Insuch a rendering system, a base coordinate 810 is first identified thatwill serve as the starting point (either directly or indirectly) for allother graphic information rendered on a display. In the presentlyillustrated embodiment, all points on the Cartesian grid are expressedin the form of pixels. Other embodiments may utilize any type of scalingunit so long as it provides a consistent basis for determining distancebetween points.

Rendering a graphic from the base coordinate 810, a second coordinate820 may be identified. The second coordinate 820, in the presentexample, may be reflected formulaically as a base coordinate plus amodifier in the context of an overarching constant (base+%modifier+f(x)). In this example, the constant has been reflected aspixels, more specifically one pixel; scaling units other than a pixelcan be utilized as can constants other than one. Second coordinate 820,in this instance, is rendered as a result of being located on the Y-axisat a 4-times percentage increase over the Y-axis location of basecoordinate 810 in the context of a 1 pixel scaling unit. In other words,coordinate 820 is located 4 pixels higher on the Y-axis as is basecoordinate 810.

Third coordinate 830 is depicted in a similar fashion wherein it islocated at 4-times the pixel percentage on the X-axis as from secondcoordinate 820 and 4-times the pixel percentage of the X-axis and Y-axisas compared to base coordinate 810. Base coordinate 810 in conjunctionwith second 820 and third coordinates 830 result in the rendering of atriangle 840 on the display.

A coordinate layout system is not meant to be limited to only aCartesian grid but also encompasses, for example, polar coordinates anda three dimensional grid (i.e., x*y*z).

The final rendering of one object can be used as a base coordinate for asecond object in a semantic coordinate layout system. For example, thirdcoordinate 830 can be utilized as a second base coordinate 850 for a newobject. That is, the upper right hand corner of a first object (triangle840) serves as the bottom left corner of a second object (square 850).

For further example, utilizing an exemplary semantic coordinate layoutsystem, a first base coordinate might be identified as the upper righthand corner of another object (e.g., coordinate 850). In some instances,however, the location of the upper right hand corner of another objectwill not be known as a layout engine 700, for example, may still bedetermining the locale of certain information to be rendered.

Once the layout engine 700 evaluates the layout of a particular device,the actual location of the upper right hand corner of another object isascertained. Once that location is ascertained (e.g., coordinate 850),semantic coordinates allow for the rendering of additional coordinatesand/or the entire remainder of an object. This late binding of locationsthrough the use of a semantic specification (e.g., the upper left ofobject Y is ten pixels from the lower right of object X) further allowsfor automatic adjustment of layout.

Formulaic expression may also be used in a semantic coordinate layoutsystem. For example, (Lower Y=Upper Right X+20% of Width of X+10 DisplayUnits). In this example, none of the values are immediately calculableuntil the layout engine 700 renders object Y and a relationship betweendisplay unit and pixel (or some other base measurement) is determined bythe layout engine 700.

The exemplary formulas provided herein are not meant to be limiting.Various other formulaic entries may be utilized in the rendering andlayout of objects and information.

In some embodiments of the present invention, the rendering of objectsor information in a scalable user interface that operates agnosticallyof device or platform will often utilize a combination of vectorgraphics, a grid system and/or a semantic coordinate layout system. Forexample, a line is specified as being drawn from point x1, y1 to pointx2, y2 with a specified line width and perhaps a specified arc. Pointsx1, y1 and x2, y2 may be determined as the result of utilizing a gridlayout system. Individual objects may then be rendered in light of thesecoordinates using vector graphics. Additional objects may then beexpressed as semantic coordinates considering certain coordinates ofpreviously rendered objects.

Alternatively, some embodiments of the present invention may utilizebitmapping/rasterization in the context of a particular layout system(e.g., an object is rendered utilizing a combination of techniquesindividually and in conjunction with one another). For example,utilizing a semantic coordinate system, a base coordinate for a displaybutton may be indicated as ten display units right from a previouslyrendered object. The actual button, however, may be a bitmap in alibrary and is rendered on the screen with its lower-left corner beingat the base coordinate as determined by a semantic coordinate layoutsystem.

The layout engine 700 of FIG. 7A may operate in conjunction with variousrendering tools to result in scalable or intelligently placed graphicevents. For example, the layout engine 700 may determine that an inputrequest 710 to render a particular button or icon cannot be displayed asrequested following a query to the rules engine 720. The logic engine730, however, may instead determine what aspects of the particular iconneed be adjusted or scaled (e.g., adjusting the display unit orconstant) whereby the icon is still rendered but on a smaller scale inaccordance with various vector graphic or coordinate layout techniques.

It should further be noted, as is illustrated in FIG. 9, that therendering of graphic events or information can occur hierarchically. Forexample, display 900 may exhibit certain limitations as are recognizedby a rules engine 720 (FIG. 7A). Limitations on display or other eventscan also be hierarchical and also stored in the rules engine 720.

An example of hierarchical limitations is shown whereby a sidebar 910 iscomprised of various smaller icons 920-940. Sidebar 910 may impose itsown independent limitations as they pertain to smaller icons 920-940,that is, smaller icons 920-940 cannot exceed the width and height of thesidebar 910 just as sidebar 910 may not exceed the limitations ofdisplay 900.

A similar situation exists with text boxes 950 and 970. Both text box950 and text box 970 are comprised of smaller display elements 960 and980-990, respectively. Display elements 960 and 980-990 must not exceedthe limitations imposed by text boxes 950 and 970 just as those textboxes must not exceed the limitations of display 900.

Furthermore, limitations can exist between the smaller sub-elements ofthe display. For example, icons 920-940 may have a limitation whereinthey cannot come within X pixels of one another due to color schemesthat might begin to ‘blend’ together and result in a deterioratedviewing experience.

Similarly, display elements 980 and 990 may be fixed as to a certainsize that cannot be scaled any larger or smaller due to the amount oftextual information contained therein where, if reduced any further thanits default font size, would render the amount of text illegible.

FIG. 10A illustrates a menu 1000 with available and not-availableoptions as is known in the prior art. Menu 1000 illustrates a number ofavailable menu items 1010 such as “New” and “Open.” Menu 1000 alsodisplays a number of not available menu items 1020 such as “Close,”“Save” and “Properties.”

Available menu items 1010 are those menu items or commands that arepresently available for execution, for example, opening a new file oropening an existing file. Not available menu items are those menu itemsor commands that are not presently available for execution due to anynumber of factors. For example, an actual file or document may not beopen. In such a case, a non-existent file cannot be closed or saved.Similarly, properties as to a non-existent file cannot be displayed.Should a file actually be opened, it is possible that not available menuitems 1020 may become available menu items 1010 as that now open file ordocument can now be closed, saved or have its properties reviewed.

In the prior art, not available menu items 1020 are usually displayed as‘grayed out.’ That is, while available menu items 1010 are displayed ina generally prominent text and can be selected either through, forexample, highlighting with a mouse or keypad; a macro or othercombination of key combinations (e.g., Ctrl+N in Microsoft® Word resultsin a new document opening), those items that are not available (notavailable menu items 1020) are generally displayed in a less prominenttext (e.g., a light gray color that still allows for readability butindicates its unavailability as menu command).

In applications with a large hierarchy of menu commands or menu commandswith various levels (e.g., File-Open-Folder-File Name), selecting orexecuting an available menu command 1010 often takes up a large amountof screen space due to a multi-level menu tree or various other menuscreens, tabs and so forth. In a device with limited display space(e.g., a mobile device), such a complex menu-tree can obfuscate theentire display or, in some instances, may not be subject to display inany form due to the number of levels and/or menus and processing orother display limitations of any particular device.

Even in applications with generally straight forward menu displays, alarge number of menu commands can cause the menu to overlap beyond theheight of the screen thereby causing the necessity of utilizing a scrollor elevator bar. While scroll or elevator bars can artificially provideadditional space by scrolling available menu commands 1010 up and downthe screen, operating such a scroll bar in a limited display area isdisadvantageous in that operating minute display commands, such as ascroll bar, with generally small operational controls on a mobile deviceis more difficult than on a desktop or even a laptop personal computer.

Further, the scroll bar will cause certain available menu commands 1010to disappear from the screen as available menu commands 1010 arescrolled up and down by the user. To do so might cause a particularcommand of importance or interest to a user to disappear as they viewother available menu commands 1010. Part of this difficulty is a resultof the integration of all menu commands on the menu, that is, bothavailable menu commands 1010 and not available menu commands 1020. Forexample, a particular menu might comprise ten various commands. Despitethe fact that only two of those commands might be available menucommands 1010 as a result of the current state of the device or anapplication, the remaining eight not available menu commands 1020 willstill be displayed thereby utilizing large amount of screen displayspace.

FIG. 10B illustrates a menu 1030 exhibiting intelligent prioritizationof menu commands as governed by their present availability according toan embodiment of the present invention. In FIG. 10B, the state of thedevice or application is the same as that of the prior art menu asillustrated in FIG. 10A. In FIG. 10B, however, only available menucommands 1040 are displayed. This results in savings of space, memoryand processing power as, for example, only two menu commands—New andOpen—are displayed (available menu commands 1040). In such an embodimentof a menu 1030, it would not be necessary to utilize a scroll bar toaccess various menu commands as the menu 1030 is reduced in size due tothe non-display of not available menu commands 1020.

Should the state of the device or application change, however, thosecommands that are presently not displayed but otherwise relevant to thechange n device state would then be added to the list of available menucommands 1040 and displayed on the menu 1030.

FIG. 10C illustrates a menu 1050 exhibiting intelligent prioritizationof menu commands as governed by user preference according to anembodiment of the present invention. In FIG. 10C, the state of thedevice is such that a menu would normally, for example, display ten menucommands if it were a type of a menu as found in the prior art of FIG.10A. In FIG. 10C, however, only preferred available menu commands 1060are displayed; preferred available menu commands 1060 in this particularembodiment are not just those commands capable of execution but thosecommands capable of execution and whose display presence is preferred bythe user of the mobile device.

For example, in menu 1050 the display of ten available menu commands1060 would still occupy a large amount of space on most mobile devicesdespite the fact that, for example, five additional commands are notdisplayed as a result of them being not available. In this particularembodiment, the mobile device—as a result of logic contained in, forexample, an abstraction layer—will recognize that of the ten availablemenu commands, the user of the mobile device only utilizes three ofthose menu commands on any regular basis. The mobile device will thendisplay only those three menu commands as preferred available menucommands 1060. Those commands that are not preferred but are otherwiseavailable will not be displayed 1070.

This results in a better end user experience through savings of space,memory and processing power in addition to smoother and more navigableinterfaces as only those available menu commands actually needed by theuser are displayed. In such an embodiment of a menu, it would not benecessary to utilize a scroll bar to access various menu commands as themenu 1050 is reduced in size due to the non-display of not availablemenu commands as well as available menu commands that are not preferredby the user.

Preferred available menu commands 1060 can be those commands asrecognized by the device as being preferred (e.g., in 50 previous usesof a particular menu, only two commands out of ten were utilized) or canbe identified manually be the user. Preferred available menu commands1060 can also be set by default by the manufacturer of a device oragnostic platform. For example, it might be recognized in the industrythat while particular menu commands might be useful, they are onlyutilized by a small percentage of the public utilizing the device. Assuch, only those commands used by the general public are displayed whenavailable.

Should the state of the device or application change, however, thosecommands that are presently not displayed but preferred would then beadded to the list of preferred available menu commands 1060 anddisplayed on the menu 1050 with regard to the state change invoking theavailability of certain commands.

The same intelligence utilized in a menu can also be utilized withregard to display icons. FIG. 11A illustrates a device display 1100wherein limitations as to screen size, pixels or other factors do notaffect the display of a series of icons 1110-1140. These icons 1110-1140may be for such functions as telephone, calendar, Internet and contacts.

FIG. 11B illustrates a device display 1150 wherein certain limitations,screen-width for example, make it impossible for the display of fouricons of a given size. In this example, the device may display onlythose icons that are preferred by the user 1060-1070 such as calendarand telephone. Like the menu displayed in FIG. 10C, these preferredicons 1060-1070 may be the result of default preferences, user-inputpreferences or intelligent decision making by logic in a device. Thislogic may be similar to the logic used in a layout engine as illustratedin FIG. 7A.

FIG. 12 illustrates a cross-platform event engine 1200 as utilized in anexemplary embodiment of the present agnostic user interface.Cross-platform event engine 1200 comprises an event library 1210 and alogic engine 1220. An embodiment of the cross-platform event engine 1200translates a first platform's events (e.g., key down, up, or centerpress) into event formats recognizable by a second platform wherebysoftware code can operate unaltered on different platforms withdifferent event encoding and/or event sets. An embodiment of thecross-platform event engine 1200 also ensures the presence andstandardization of certain events (e.g., press-and-hold and keyrepeats).

Event library 1210 comprises information as it pertains to theoccurrence of certain events on various devices and/or platforms. Forexample, event engine 1210 might be programmed to understand that bypressing and holding a particular button on a particular mobile devicefor a particular period of time (e.g, the ‘1’ number key for two secondson a certain device) will result in the mobile device activating itstelephone functionality and automatically dialing into a voice mailaccount assigned to that particular mobile device.

The information residing in the event library 1210 can be installed byan original equipment manufacturer or may be subject to user adjustment(e.g., deactivating default settings and/or imposing new settings).Information in the event library 1210 may also be updated automaticallyduring the operation of the device or configured as the result ofintelligent determinations by the device.

For example, if the event library 1210 determines that it is resident ona device for which it does not know what event will be triggered by thetwo-second press and hold of the ‘1’ key, the event library 1210 canmake certain assumptions based on a particular series of a device butnot the exact model. This assumptive logic is similar to that of thedisplay engine as described in FIG. 7.

The event library 1210 can also receive new updates with regard todevice information during a synchronization operation with a desktop PCor server that hosts other programs related to the device (e.g., a mailforwarding program that forwards mail from the desktop to the mobiledevice). These updates might be downloaded at the desktop PC or serverautomatically or as a result of the user affirmatively downloading anupgrade or patch from the appropriate provider of that information(e.g., the device manufacturer or the agnostic interface designer).

The event library 1210 can also request the user manually provide thisinformation if an assumption or synchronization operation fails toprovide the necessary information.

An event input 1230 from the user of the device or a program running onthe device comprises a particular operation that should result in theactivation of a particular application, the display of certaininformation or the invocation of some other functionality particular tothe device. For example, the two-second hold and press of the ‘1’ numberkey should result in the launch of voice mail access on particulardevices.

Similarly, this request might be generated by a particular program as aresult of the occurrence of another particular event, for example, aninternal alarm indication (e.g., it is now 8.00 AM) may result in resultin the generation of a text box indicating a certain event is about tobegin and accompanied by an alarm sound (e.g., a repeated beep). Theexecution of particular string of code in a device (e.g., the code forgenerating the box) may comprise event input 1230 just as may theactivity of the user (e.g., press and hold of a particular key).

The event input 1230 need not be of any particular format or language solong as it may be processed by the cross-platform engine 1200 withregard to determining whether a particular application, sub-event,display, sound, etc. should be executed.

The cross-platform event engine 1200 also comprises the aforementionedlogic engine 1220. The logic engine 1220, based on an event input 1230,will query the event library 1210 to determine if the particular eventinput 1230 may be processed as requested on the particular device or ifsome adjustments will be required with regard to the particularconfiguration of the device as set forth in the event library 1210.

If the event library 1210 reflects that the event input 1230 can beidentified, processed and subsequently executed without resorting totranslation or reconfiguration of the input, the logic engine 1220 willallow the event input 1230 to result in the generation of an eventinstruction 1240.

For example, the user presses and holds the ‘1’ key for two seconds(event input 1230). The cross-platform event engine 1200 will accept theevent input 1230 and will query the event library 1210 with regard tothe event engine 1200 having received this particular input. The eventlibrary 1210 (presuming it to have been programmed with this particularinformation) will recognize that on a particular device, a two-secondpress and hold of the ‘1’ key is meant to execute a telephone call tothe user's voice mail. The event library 1210 will communicate theidentification of this operation to the logic engine 1220. The logicengine will then identify that the device is compatible with thatoperation thereby resulting in the generation of an event instruction1240 that will cause the activation of a telephone call to the user'svoice mail.

Event instruction 1240, like the event input 1230, is not of anyparticular format or language so long as it may be generated by thecross-platform event engine 1200 with regard to indicating that aparticular text and/or graphic event may be displayed on the device orthat a particular application or other operation should be executed inaccordance with the event input 1230.

Should the logic engine's 1220 query of the event library 1210 determinethat the requested operation is not immediately compatible with thepresent device (e.g., the device does not utilize a two-second press andhold for voice mail access but a three-second press and hold), the logicengine 1220 may further query the event library 1210 to determine whatthe particular configuration of the device allows for the identical orsimilar operation and, if so, whether the particular event request 1230can be converted or translated into a request that will result in theidentical or similar operation.

For example, if the device recognizes that a two-second press and holdis being executed, the logic engine 1220, after having accessed theevents library 1210, might recognize that this particular event isusually associated with voice mail access on particular devices. Thelogic engine 1220, in conjunction with the events library 1210, willdetermine that while voice mail access is possible on the presentdevice, access requires the execution of a three-second press and holdevent. The cross platform event engine 1200 will convert the initialrequest (1230) into the proper request whereby access to voice mail willoccur as the result of an event instruction 1240.

Information pertaining to possible translation or conversion might alsoreside directly in the logic engine 1220 or at a locale on the deviceaccessible by the engine 1220. For example, information pertaining tocommon events might be cached in the logic engine 1220 or in memory (notshown) accessible by the logic engine 1220.

Similarly, the logic engine 1220, in certain embodiments, may betrained, whereby the logic engine 1220 begins to recognize a repeatedevent input 1230 and without query to the event library 1210 understandsthat such an event is possible but initiated through a different processas defined by the event library 1210. Through the training of the logicengine 1220 and the now absent need for continued queries to the eventlibrary 1210, the processing speed of an event instruction 1240 isincreased.

The logic engine 1220, in some embodiments, may also be expresslyinstructed by the user (e.g., through pre-programming or a query duringprocessing) to respond to a particular difference in configuration asidentified by the event library 1210 in a particular manner. Forexample, if the event input 1230 pertains to the particular timing of akey press to activate a particular application, the user mightpre-program the logic engine 1220 to automatically launch thatapplication (e.g., as a default) instead of querying the events library1210 and perhaps coming to an erroneous result as to the particularnature of the event and how it might be processed in its nativeenvironment.

In that regard, the cross-platform events engine 1200 can further beconfigured to recognize that the user of the device is perhaps mostfamiliar with a particular operating system platform or mobile device.In that regard, the logic engine 1220, in conjunction with event library1210, may consider, in the event there is a disparity as to what event auser actually seeks to execute through an event input 1230, those eventsthat relate to the user's more familiar platform or device prior toconsidering any other particular events as they relate to less familiardevices or platforms.

For example, a first device might associate a two-second press and holdwith attempting to access voice mail. A second device might associate atwo-second hold with launching an electronic mail program and wirelesslyaccessing the Internet. On a separate device running a cross-eventsplatform 1200, the events library 1210 will be programmed withinformation concerning events as they relate to both devices (e.g., atwo-second press and hold relating to voice mail on the first device andelectronic mail on the second). When an event input 1230 (two-secondbutton hold) is received by the cross-platform event engine 1200, thelogic engine 1220 will query the event library 1210 and recognize thatsuch an input 1230 can have a differing result between devices. Havingbeen previously programmed to note that the user formerly was a ‘firstdevice’ user, however, the logic engine 1220 will elect to convert theinput 1230 to an input compatible with voice mail access therebyresulting in voice mail access (through instruction 1240) rather thanelectronic mail and Internet access as would be appropriate had the userbeen a former ‘second device’ user.

An embodiment of the cross-platform event engine 1200 also allows forcross-platform representation of strings and other executables.

Like the layout engine in FIG. 7B, the event library 1210 of thecross-platform event engine 1200 may be integrated with the abstractionlayer 420 of the virtual platform 400 that allows for theinteroperability of a particular user interface on any variety ofdevices and/or platforms. This integration may also include integrationwith the layout engine 700. While the cross-platform event engine 1200and virtual platform 400 need not necessarily be physically integrated,the agnostic user interface of the present invention requires that thetwo components at least be capable of communicating with one another asto allow for the translation of what might be a foreign instruction intoan instruction otherwise comprehensible by the cross-platform eventengine 1200.

While some mobile devices now offer a full QWERTY keyboard on the deviceto allow for text entry for the purposes of, for example, generatingelectronic mail or updating a contact database, these keyboards take upa large amount of space and can cause a mobile device to be too wide ortoo large for a particular user's requirements. As such, a number ofmobile devices utilize what is known as triple-tap (sometimes referredto as triple-press) text entry. FIG. 13A illustrates a portion of akeypad 1300 as might be utilized in triple-tap text entry on a mobiledevice as is known in the prior art.

In a triple-tap device, the keypad is that of a telephone keypad withgroups of letters in alphabetical order and associated with particularnumber keys. For example, number key 2 1310 in FIG. 13A is associatedwith letters A, B and C. Similarly, number key 3 1320 in FIG. 13A isassociated with letters D, E and F.

To enter text on a device utilizing a triple-tap text entry, the usertaps the key the number of times corresponding to the position of theletter in the standard ordering. For example, to enter the letter “A,”the user presses the ‘2’ key once; to enter the letter “B,” the userpresses the ‘2’ key twice (A-B); to enter the letter “C,” the userpresses the ‘2’ key three-times (A-B-C).

The difficulty with triple-tap is that the device or platform operatingthe triple-tap text entry method must deal with segmentation issues,that is, when two characters that are mapped to the same key are enteredconsecutively (e.g., A and B on number key two 1310 as in the wordabsent or A and A on the number key two 1310 as in the word aardvark).The issue becomes when does the first ‘tap’ series end and the second‘tap’ series begin.

The typical solution to segmentation is generally known as the ‘timeoutapproach.’ Using timeout, a device determines when a user has finishedcycling through characters on a particular key. A preset timeout period,usually one to two seconds, must elapse before another character can beentered on the same key. If the user enters another character on thesame key before the timeout period has elapsed, the current character isoverwritten with the next character in order.

Using the previous example, to enter the word ‘absent,’ the user wouldtap the ‘2’ key 1310 once to enter the letter ‘A.’ The user must thenlet the timeout period of two seconds expire before tapping the ‘2’ key1310 two more times in order to enter the letter ‘B.’ If the user tapsthe ‘2’ key 1310 even once before the expiration of the timeout period,the initial ‘A’ will be overwritten by a ‘B.’

Disambiguating input, that is, removing ambiguities (e.g., when does afirst ‘tap’ series begin and a second ‘tap’ series end) from a keypadusing triple-tap can often be tedious and inefficient. An alternative totriple-tap text entry is T9® predictive text input as offered by TegicCommunications, Inc. FIG. 13B illustrates a mobile device 1330 utilizingthe T9 text-entry methodology as is known in the prior art.

T9® text-entry incorporates linguistic knowledge, in the form of adynamic dictionary and word probabilities, to perform disambiguation.Using T9® text-entry, a word is defined as any sequence of key presses.Generally, the space key (or the zero key) is used to delineate wordsand terminate disambiguation. For a given sequence of key presses, thesystem retrieves a list of words from its dictionary that could beentered with that sequence. The list is then ordered in descending orderof word probabilities and the most probable word is presented to theuser initially or, in some embodiments, automatically entered into thestring of text. If the initial prediction is incorrect, the user canscroll through the list of predicted words to try and find the correctword.

Despite the predictive intelligence of a T9®-type system, some mobiledevices will still rely on triple-tap entry in conjunction with T9® foractual entry of text. That is, a user will still utilize atelephone-type keypad as evidenced in FIG. 13A in conjunction will thepredictive analysis of T9® as shown in FIG. 13B. As such, thesegmentation issue still remains.

Normally, a user will become accustomed to the timeout period of aparticular device and learn to adjust to that period when entering text.Some systems might allow for the timeout period to be manually set oradjusted by the user. For example, if a user happens to enter text at aslow-pace, the timeout period can be extended from two-seconds to three-to four-seconds or longer depending on the user's particularpreferences. Likewise, the timeout period can be shortened if a user isa particularly fast typist. In other embodiments, the timeout period canbe the result of training (e.g., observing key press rates over thecourse of 1,000 key presses).

The difficulty arises, however, when a user switches from one device orplatform to another device or platform. The timeout period of a firstdevice may not (and often is not) the same as the second device. Assuch, the user will often experience a great deal of difficulty anddelay with regard to entering text into a device using triple-tap ortriple-tap and T9® in combination on the new device with a foreigntimeout period.

Using an agnostic interface, however, difficulties encountered with aparticular timeout period can be overcome whereby a timeout period ismade agnostic across various platforms. Certain embodiments of thepresent invention provide users with an interface experience on oneparticular device (e.g., triple-tap, T9®, eZi mode) while utilizing adifferent device.

In an embodiment of the present invention, as illustrated in FIG. 14A,an on-screen text box 1410 in a mobile device 1400 is synchronized withan off-screen text buffer 1420.

With every key press, the off-screen text buffer 1420 is populated withindicia of that particular key press. For example, if the user pressesthe ‘2’ key, the off-screen buffer 1420 is populated or ‘strobed’ withan indication that the ‘2’ key has been pressed once (e.g., 2). If theuser presses the ‘2’ key again, the off-screen buffer 1420 is clearedand re-populated or ‘strobed’ with an indicator of the ‘2’ key havingbeen pressed twice (e.g., 2, 2). Should the user then press the ‘2’ keya third-time, the off-screen buffer 1420 is again cleared andre-populated or ‘strobed’ with an indicator of the ‘2’ key having nowbeen pressed three times (e.g., 2, 2, 2). If, at any time, a particularkey is not repeated (e.g., the ‘2’ key) the off-screen buffer 1420synchronizes with the on-screen text box 1410 and populates theon-screen text box 1420 as appropriate. That is, the off-screen text box1420 will effectively ‘carriage right’ by causing population of theon-screen text box 1410 with the appropriate textual character.

For example, if the ‘2’ key is pressed once and then followed by the ‘3’key, the off-screen text buffer 1420 will populate the on-screen textbox 1410 with the letter ‘A’ and, eventually, ‘D.’ If the user pressesthe ‘2’ key twice, followed by the ‘3’ key twice, followed by the ‘6’key twice, then the on-screen text box 1410 will become populated withthe letters ‘B’ and ‘E’ and, eventually, ‘N.’

Using this off-screen and on-screen synchronization methodology, thetimeout function becomes unnecessary. The device, through using theoff-screen text buffer 1420, simply need refer to the ongoing string oftext in determining whether population of the on-screen text box 1410 isappropriate. If a key other than the initial key is pressed (e.g., ‘2’followed by ‘3’), then a right-carriage function is appropriate (e.g.,move to the next character in the word) and the on-screen text box 1410should be populated. If the same key as the initial key is pressed(e.g., ‘2’ followed by ‘2’), then there exists the possibility of athird repetition of ‘2’ and population of the on-screen text box 1410should be delayed until a right-carriage function is confirmed (i.e.,the entry of a new key).

FIG. 14B further illustrates a string of key press entries 1430 as mightbe found in an off-screen text buffer 1420 as described in FIG. 14A. Inthe present figure, the user has initially key pressed ‘7’. Number key‘7’ can be associated with the letters ‘P,’ ‘Q,’ ‘R’ and ‘S’ in additionto the number ‘7.’

In a traditional triple-tap system, the user would press the ‘7’ key andthe letter ‘P’ (being the first textual character associated with the‘7’ key) would immediately appear on the display. Immediately afterpressing the ‘7’ key, the timeout function would begin wherein aninternal timer would begin calculating the expiration of the timeoutperiod. If they ‘7’ key were pressed again during the timeout period,the previously displayed ‘P’ would be immediately converted to theletter ‘Q’ (being the second textual character associated with the ‘7’key). The timeout period would then re-commence as the user could stilldesire to enter the letters ‘R’ or ‘S’ in addition to the number ‘7.’

If the user pressed the ‘7’ key after the expiration of the timeoutperiod and following the initial display of the letter ‘P,’ however, theletter ‘P’ would remain on the display and a second letter ‘P’ wouldappear and the timeout sequence as described above would now commencefor this second textual character to be displayed. Proper display oftext is dependent upon the user properly making key presses during oroutside of the timeout period.

Using the off-screen text buffer 1420, however, the device insteadrelies on the string of key press entries 1430 versus the timeoutperiod. For example, the user has key pressed the aforementioned ‘7’ aswell as ‘3,’ ‘8,’ ‘3’ and ‘6.’ As none of the key presses involve arepeat of a key press (e.g., ‘3’ followed by ‘3’ thereby indicating theletter ‘E’), it is determined that each key press is meant to render thedisplay of the first textual character associated with each of thesenumber keys (i.e., S E V E N). The ‘0’ (space) key is followed by ‘6,’‘3,’ ‘8,’ ‘9,’ ‘6,’ ‘7,’ ‘5’ and ‘7.’ Again, as there are no repeat keypresses, it is determined that the textual display should accord withthe first textual character associated with each key (i.e., N E T W O RK S).

FIG. 15 illustrates a method 1500 for utilizing the off-screen textbuffer 1420 as described in FIGS. 14A and 14B. In step 1510, theoff-screen text buffer (1420) is cleared and made ready for the entry ofa first key press indicator. In step 1520, the user makes a key pressand an indicator of that key press (e.g., ‘7’) is entered into theoff-screen text buffer (1420; 1430).

The user will then make a subsequent key press 1530 (e.g., ‘3’) and thedevice then determines 1540 if the subsequent key press 1530 is a repeatcharacter as compared to the previously entered character (e.g.,‘3’-‘3’). If the subsequent key press 1530 is a repeat character, theoff-screen text buffer is cleared 1550 and the off-screen text buffer isre-populated 1560 with all previous indicators plus the most recentlyentered subsequent key press indicator. The device will then await theentry of a subsequent key press 1530.

If the subsequent key press 1530 is not a repeat character (e.g.,‘7’-‘3’-‘8’), then the device will populate 1570 the on-screen text box1410 with the appropriate textual characters thus far entered (e.g., ‘S’and ‘E,’ to be followed, presumably, by the letter ‘V’). The device willthen continue with the entry of a particular word 1580 in a similarfashion.

With the use of T9®, a similar system of on-screen text box 1410 andoff-screen text buffer 1420 and method 1500 are utilized. With T9®,however, the context of a string of key presses (e.g., string 1430) isparsed to make intelligent language determinations. The length of thecontext (e.g., the length of the string) can be set as a matter ofdefault or by the user of the device or based upon particularmanufacturer setting determined by the particular parser utilized in adevice. For example, context may be one word, one sentence or even afull paragraph dependent of the intelligence of the T9®-type systemused.

An embodiment of the present agnostic interface may also allow forpictorial-language entry, for example, Japanese-language entry in Kanji.Through an optional translation language engine, for example, aparticular entry in Kanji in the on-screen text box 1410 can beassociated with a character entry in the off-screen text buffer 1420. Atranslation engine may be embodied in an abstract layer 420 and/orthrough a rules engine or information library or module.

FIG. 16 illustrates an exemplary method 1600 for utilizing a layoutengine to display graphics and/or text in an embodiment of the presentinvention.

A request 1610 will first be made of the layout engine to render certaintext or graphics information. In accordance with this request 1610, aquery will be made to the rules engine in step 1620 to obtaininformation as to whether or not the particular device or platform canprocess the request 1610 as initially submitted to the layout enginedependent upon certain constraints of the particular device or platform.The layout engine will then make that determination in step 1630 as towhether the constraints of the device allow processing of the request1610.

If the request 1610 can be processed, the layout engine will allowdisplay of the requested graphics and/or text 1640 through thegeneration of an output instruction as discussed in the context of FIG.7A. If the request 1610 cannot be processed, the layout engine willfurther determine the constraints of the particular device in step 1650;that is, what aspect of the present device is preventing the display ofthe text and/or graphics information as submitted through request 1610.The layout engine, in step 1660, will then determine the scope of theoriginal request and how to best display the requested text and/orgraphics information while staying within the scope of that request(e.g., rendering a graphic in red as opposed to the requested maroon).The layout engine, through an output instruction, will then rendergraphics and/or text information in step 1670 that corresponds to theconstraints of the particular device and the original scope of therequest 1610.

During step 1620, if the query to the rules engine results in nodetermination of particular limitations of the device, an optional step1680 with regard to obtaining that information can be made beforerepeating the query to the rules engine as described in step 1620. Thisoptional information obtaining step 1680 can be the result of asynchronization operation, a software update, manual input or anintelligent assumption as made by the layout engine.

FIG. 17 illustrates an exemplary method 1700 for utilizing across-platform events engine to execute cross-platform events in anative environment in an exemplary embodiment of the present invention.

In step 1710, an event as input by the user or generated by a device isreceived by the cross-platform events engine. In step 1720, the eventsengine will query the events library to determine the nature of therequest (e.g., what application should be executed as a result of atwo-second button press?).

If the event request received 1710 by the engine can be processed on theparticular device—as determined in step 1730—the engine will allow forexecution 1740 of the particular application or occurrence of otheractions that result from the initially received event request.

If the event request received 1710 by the engine cannot be processed onthe particular device, the engine will further query the library todetermine why the event cannot be processed in step 1750. For example,is an action associated with a two-second button press, is there amultitude of actions associated with a two-second button press or is anillegal operation associated with a two-second button press (e.g., theassociated event is the launch of a non-present application). In thecase of a multitude of operations being associated with the eventreceived in step 1710, the events library might be programmed to notethat the user of the device is a former user of a particular device aswould be discovered during optional query step 1790. In such asituation, the events engine would associate that former device with thereceived event 1710 before associating it with a second or any otherevent.

In step 1760, the events engine will, having determined the operationallimits of the device in step 1750, determine whether the initial eventrequest received in step 1710 can be converted to a request that can beprocessed by the device (e.g., a two-second hold for voice mail on onedevice is equivalent to a three-second hold on the present devicethereby requiring the conversion of information related to a two-secondhold as information related to a three-second hold).

If the initial request received in step 1710 cannot be converted, thedevice will return an illegal operation error notification in step 1770.The device will then query the user whether they wish to allocate aparticular action or result with the initially received event request instep 1775. For example, the present device may not have any actionassociated with a two-second button press but will allow the user toassign one. Having assigned an action to the event in step 1775, thedevice may then re-initiate the sequence be providing this newinformation to the event library and initiating query step 1720.

If the initial request received in step 1710 can be converted,conversion of that request will occur in step 1780. Various techniquesare known in the art for converting one informational format to another.For example, transcoding or ‘spoofing’ one request as another throughproviding an alias or ‘wrapper’ around the actual request whilepresenting it as the aliased request. Following conversion of therequest in step 1780, the event or action associated with the requestwill be executed in step 1785.

FIGS. 18A and 18B illustrate the management of information displayed ona mobile device 1800 using five-way navigation. Shown on the display ofmobile device 1800 are a series of electronic mail messages 1810 asmight be displayed in a mailbox feature on a mobile device.

In order to manage electronic mail messages, for example, it isnecessary to move a highlight bar to a particular message, open themessage, enter a delete command either manually, through a drop-downmenu or through icon selection, and finally confirm deletion of amessage before the message is finally removed from a mobile device'smailbox. In systems where a mobile device is synchronized with a desktopmailbox (e.g., Microsoft® Outlook), an additional confirmation is oftenrequired as to whether the user wishes to delete the message only on themobile device, only on the desktop or on both the handheld and thedesktop. The process is then repeated for each message to be deleted.For a user that receives a large number of electronic mail messages ontheir mobile device, this can be extremely tedious and time consuming inaddition to wasting battery and processing resources.

FIG. 18B illustrates the use of a five-way navigation control 1820 tomanage information such as electronic mail. Using the five-waynavigation control 1820 allows a user to move an icon, cursor or otherindicator on a display up, down, left, and right in addition to aconfirmation or ‘down click’ feature wherein the user presses down onthe center of the navigation tool in an action sometimes equivalent tothe pressing of the carriage return key on a keyboard. Five-waynavigation allows a user to operate various functionalities of a mobiledevice with one hand and without the use of, for example, a stylus.

In FIG. 18B, as in FIG. 18A, a list of five electronic mails ispresented. Should the user wish to delete two of those electronic mails(1830 and 1840), using traditional management methods would require theuser to highlight the first message (1830), open the message, enter adelete command either manually, through a drop-down menu or through iconselection and then confirm deletion of the message. Using an exemplaryfive-way navigation technique, the user can navigate down the message tobe deleted (1830) by pressing down on the navigation tool 1820 and thenpressing the navigation tool 1820 to the right and then down clickingwhereby the message is then highlighted and selected for further action,in this instance, deletion.

The user can then press the navigation tool 1820 down two more times toarrive at a second message to be deleted (1840). The user can thenhighlight the message for deletion as in the instance of message 1820.The user can then, at an appropriate time, select a ‘delete all’ commandwherein all highlighted messages are then deleted.

Using five-way navigation is not limited to deletion of messages. A usercould also select files to review (e.g., where the user has access todesktop files) or could also manage files or messages to be placed inparticular mobile device folders for organization using similarnavigation and highlighting techniques. Similarly, a user could selectvarious contacts in a directory to electronically ‘beam’ (e.g., througha Bluetooth® or infrared transmission) to another user.

The above-described embodiments are exemplary. For example, the presentagnostic interface also allows for building various applications (e.g.,gaming applications) across various platforms and devices. One skilledin the art will recognize and appreciate various applications of thedisclosed invention beyond those presently described here. Thisdisclosure is not meant to be limiting beyond those limitations asexpressly provided in the claims.

1. A system for handling event input between disparate platforms, thesystem comprising: a processor; and a memory containing instructionsexecutable by the processor whereby the system is operable to: recognizean event associated with a first platform, the event having semanticcontent; translate the event into a form recognizable by a secondplatform; and communicate the event in the translated form to the secondplatform, wherein the second platform is configured for effectuating thesemantic content of the event.
 2. The system of claim 1, whereintranslating the event into a form recognizable by a second platformincludes translating the event into a syntax recognizable by the secondplatform.
 3. The system of claim 1, wherein the instructions fortranslating the event into a form recognizable by the second platformare configured by an original equipment manufacturer.
 4. The system ofclaim 1, wherein the event is automatically generated by the system. 5.The system of claim 1, wherein the event is a request to invoke afunctionality of the system.
 6. The system of claim 1, wherein the eventis generated in response to user input received by the system.
 7. Thesystem of claim 6, wherein the user input received by the system is akey press.
 8. The system of claim 1, wherein the event is generated inresponse to a system occurrence.
 9. The system of claim 1, wherein theevent includes information generated by the event.
 10. A device forhandling event input between disparate platforms, the device comprising:a communication interface; a control system communicatively coupled tothe communication interface and comprising a processor and a memorycontaining instructions executable by the processor whereby the deviceis operable to: recognize an event associated with a first platform, theevent having semantic content; translate the event into a formrecognizable by a second platform; and send the event in the translatedform to the second platform, wherein the second platform is configuredfor effectuating the semantic content of the event.
 11. The device ofclaim 12, wherein translating the event into a form recognizable by asecond platform includes translating the event into a syntaxrecognizable by the second platform.
 12. The device of claim 12, whereinthe instructions for translating the event into a form recognizable bythe second platform are configured by an original equipmentmanufacturer.
 13. The device of claim 12, wherein the event isautomatically generated by the device.
 14. The device of claim 12,wherein the event is a request to invoke a functionality of the device.15. The device of claim 12, wherein the event is generated in responseto user input received by the device.
 16. The device of claim 15,wherein the user input received by the device is a key press.
 17. Thedevice of claim 10, wherein the event is generated in response to asystem occurrence.
 18. The device of claim 10, wherein the eventincludes information generated by the event.
 19. A method for eventhandling between disparate platforms, wherein the method includes:Recognizing the event associated with a first platform, the event havingsemantic content; translating the event into a form recognizable by asecond platform; and sending the event in the translated form to thesecond platform, wherein the second platform is configured foreffectuating the semantic content of the event.
 20. The method of claim19, wherein translating the event into a form recognizable by a secondplatform includes translating the event into a syntax recognizable bythe second platform.
 21. The method of claim 19, wherein the event isautomatically generated by the device.
 22. The method of claim 19,wherein the event is a request to invoke a functionality of the device.23. The method of claim 23, wherein the event is generated in responseto user input received by the device.
 24. The method of claim 19,wherein the event is generated in response to a system occurrence. 25.The method of claim 19, wherein the event includes information generatedby the event.
 26. A non-transient computer-readable medium containingprogram instructions for causing a device to perform the method ofhandling event input between disparate platforms, the method comprising:recognizing an event associated with a first platform, the event havingsemantic content; translating the event into a form recognizable by asecond platform; and sending the event in the translated form to thesecond platform, wherein the second platform is configured foreffectuating the semantic content of the event.
 27. Thecomputer-readable medium of claim 26, wherein translating the event intoa form recognizable by a second platform includes translating the eventinto a syntax recognizable by the second platform.
 28. Thecomputer-readable medium of claim 26, wherein the event is automaticallygenerated by the device.
 29. The computer-readable medium of claim 26,wherein the event is generated in response to a system occurrence. 30.The computer-readable medium of claim 26, wherein the event includesinformation generated by the event.